A graphical user interface (GUI) test (hereinafter referred to as “test”) is a sequence of interactions with a computer system or software under test (hereinafter referred to as “SUT”). The test communicates with its users by obtaining input and providing output through a GUI, for the purpose of assessing the conformance of the system in relation to a set of system requirements.
Because these tests are often repeated, the sequence of operations is often recorded in the form of a test script (hereinafter referred to as “script”). A script is an encoding of the test in a form that is acceptable to a software program called a test-automation tool (hereinafter referred to as “tool”). Given a script in acceptable form, the tool can simulate a user performing the test's interactions with the SUT, and record and analyze test results.
While the interactions or operations typically need to be reproducible for testing purposes, this sequence is not fixed for all executions of the script. The effects of previous interactions can influence the order or presence of particular test interactions, as can other manifestations of tool state when executing a script. The decisions that determine which sequence of interactions will be performed when executing a script are called test logic (hereinafter referred to as “logic”).
In automated test execution, a script's logic is typically encoded in the form of a software program. This program contains GUI-interaction commands (hereinafter referred to as “GUI commands”) that, when executed, simulate particular user interactions through the SUT GUI. It is the script's logic that determines which GUI commands are executed, how frequently, and in what order. GUI commands generally take the form of GUI calls; more specifically, function-, procedure-, or object-oriented method-calls to tool-specific methods that cause the specified user interaction to be simulated.
A GUI command is characterized by the particular GUI control(s), also known as widget(s), that it causes to be exercised, and by any data that is input to, or read from, these controls. Examples of such data are text strings that are presented to the SUT through the GUI, or that are presented to the user (or tool) by being displayed in the GUI. Other examples include screen locations, encoded as coordinates of the cursor at the time when GUI events, such as keyboard input or mouse clicks, take place. GUI command data is communicated through GUI calls by parameters and return values. Such GUI controls are identified in one of three ways:
1) as a parameter to the GUI call, for example:
PushRadioButton(GuiRoot.custInfo.title, “Dr.”).
2) as the object to which the GUI call is applied, in an object-oriented method call, for example:
GuiRoot.custInfo.name.setText(“Pablo Santiago”); and
Browser( ).Page(“customerInfo”).childNamed(“nameText”).
3) through context (e.g., a “selected” or “current” object maintained by the script or tool) that may be set using a call or assignment to script or system variable, for example:
Browser( ).Page(“customerInfo”).childNamed(“nameText”).select( ); and
Browser( ).inputChars(“Pablo Santiago”);—text field in context
Numerous tools are available, each with their own script acceptability requirements. This poses a problem when the tool for which a script was created is unavailable to those charged with executing the test. This may occur in numerous situations. For example, this may occur when tests are shared between groups with different automation policies; when tools that are used are changed due to licensing cost concerns; and when tools have become obsolete while test assets retain value. In such situations, the original scripts must be translated in order to be executed. Scripts are a form of computer program, and the translation of programs, in general, poses a very difficult problem. Translation by hand is very expensive, especially when a large number of tests exist, as is often the case. Thus, a need exists for automated script translation techniques that overcome these and other limitations.